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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo defines a new email header field, Archived-At:, to provide 
a direct link to the archived form of an individual email message. 
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Introduction 


[RFC2369] defines a number of header fields that can be added to 
Internet messages such as those sent by email distribution lists or 
in netnews [RFC1036]. One of them is the List-Archive header field 
that describes how to access archives for the list. This allows 
access to the archives as a whole, but not an individual message. 


There is often a need or desire to refer to the archived form of a 
single message. For more detailed usage scenarios, please see 
Section 3.3. This memo defines a new header, Archived-At, to refer 
to a single message at an archived location. This provides quick 
access to the location of a mailing list message in the list archive. 
It can also be used independently of mailing lists, for example in 
connection with legal requirements to archive certain messages. 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in [RFC2119]. 


Header Field Definition 
1. Syntax 


For the Archived-At header field, the field name is "Archived-At". 
The field body consist of a URI [STD66] enclosed in angle brackets 
(7’<’, '>"’). The URI MAY contain folding whitespace (FWS, [RFC2822]), 
which is ignored. Mail Transfer Agents (MTAs) MUST NOT insert 
whitespace within the angle brackets, but client applications SHOULD 
ignore any whitespace, which might have been inserted by poorly 
behaved MTAs. The URI points to an archived version of the message. 
See Section 3.1 for more details. 


This header field is subject to the encoding and character 
restrictions for mail headers as described in [RFC2822]. 


More formally, the header field is defined as follows in Augmented 
BNF (ABNF) according to [RFC4234]: 


archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF 
folded-URI = <URI, but free insertion of FWS permitted> 


where URI is defined in [STD66], and CRLF and FWS are defined in 
[RFC2822]. 


To convert a folded-URI to a URI, first apply standard [RFC2822] 
unfolding rules (replacing FWS with a single SP), and then delete any 
remaining un-encoded SP characters. 
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This syntax is kept simple in that only one URI per header field is 
allowed. In this respect, the syntax is different from [RFC2369]. 
Also, comments are not allowed. 


2.2. Multiple Archived-At Header Fields 


Each Archived-At header field only contains a single URI. If it is 
desired to list multiple URIs where an archived copy of the message 
can be found, a separate Archived-At field per URI is required. 
Multiple Archived-At header fields with the same URI SHOULD be 
avoided. An Archived-At header field SHOULD only be created if the 
message is actually being made available at the URI given in the 
header field. 


If a message is forwarded from a list to a sublist and both lists 
support adding the Archived-At header field, then the sublist SHOULD 
add a new Archived-At header field without removing the already 
existing one(s), unless the header field is exactly the same as an 
already existing one, in which case the new header field SHOULD NOT 
be added. 


2.3. Interaction with Message Fragmentation and Reassembly 


[RFC2046] allows for the fragmentation and reassembly of messages. 
Archived-At header fields are to be treated in the same way as 
Comments header fields, i.e., copied to the first fragment message 
header on fragmentation and back from there to the header of the 
reassembled message. 


This treatment has been chosen for compatibility with existing 
infrastructure. It means that Archived-At header fields in the first 
fragment message MAY refer to an archived version of the whole, 
unfragmented message. To avoid confusion, Archived-At headers SHOULD 
NOT be added to fragment messages. 


2.4. Syntax Extension for Internationalized Message Headers 


There are some efforts to allow non-ASCII text directly in message 
header field bodies. In such contexts, the URI non-terminal in the 
syntax defined in Section 2.1 is to be replaced by an 
Internationalized Resource Identifier (IRI) as defined in [RFC3987]. 
The specifics of the actual octet encoding of the IRI will follow the 
rules for general direct encoding of non-ASCII text. For conversion 
between IRIs and URIs, the procedures defined in [RFC3987] are to be 
applied. 
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5. The X-Archived-At Header Field 


For backwards compatibility, this document also describes the 
X-Archived-At header field, a precursor of the Archived-At header 
field. The X-Archived-At header field MAY also be parsed, but SHOULD 
not be generated. 


The following is the syntax of the X-Archived-At header field in ABNF 
according to [RFC4234] (which also defines SP): 


obs-archived-at = "X-Archived-At:" SP URI CRLF 
The X-Archived-At header field does not allow whitespace inside URI. 
Implementation and Usage Considerations 
1. Formats of Archived Message 


There is no restriction on the format used to serve the archived 
message from the URI in an Archived-At header field. It is expected 
that in many cases, the archived message will be served as (X)HTML, 
as plain text, or in its original form as message/rfc822 [RFC2046]. 
Some forms of URIs may imply the format in which the archived message 
is served, although this should not be relied upon. 


If the protocol used to retrieve the message allows for content 
negotiation, then it is also possible to serve the archived message 
in several different formats. As an example, an HTTP URI in an 
Archived-At header may make it possible to serve the archived message 
both as text/html for human consumption in a browser and as 
message/rfc822 for use by a mail user agent (MUA) without loss of 
information. 


-2. Implementation Considerations 


Mailing list expanders and email archives are often separate pieces 
of software. It may therefore be difficult to create an Archived-At 
header field in the mailing list expander software. 


One way to address this difficulty is to have the mailing list 
expander software generate an unambiguous URI, e.g., a URI based on 
the message identifier of the incoming email, and to set up the 
archiving system so that it redirects requests for such URIs to the 
actual messages. If the email does not contain a message identifier, 
a unique identifier can be generated. 
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Such a system has been implemented and is in productive use at W3C. 
As an example, the URI 

"http: //www.w3.org/mid/0I5U00GO08DFGCR@mailsj—-vl.corp.adobe.com", 
containing the significant part of the message identifier 
"<OI5U00GO8DFGCR@mailsj-vl.corp.adobe.com>", is redirected to the URI 
of this message in the W3C mailing-list archive at 
http://lists.w3.org/Archives/Public/uri/20040ct/0017.html. 


Source code for this implementation is available at 
http://dev.w3.org/cvsweb/search/, in particular 
http://dev.w3.org/cvsweb/search/cgi/mid.pl and 
http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. These locations may 
be subject to change. 


When using the message identifier to create an address for the 
archived mail, care has to be taken to escape characters in the 
message identifier that are not allowed in the URI, or to remove 
them, as done above for the "<" and ">" delimiters. 


Implementations such as that described above can introduce a security 
issue. Somebody might deliberately reuse a message identifier to 
break the link to a message. This can be addressed by checking 
incoming message identifiers against those of the messages already in 
the archive and discarding incoming duplicates, by checking the 
content of incoming duplicates and discarding them if they are 
significantly different from the first message, by offering multiple 
choices in the response to the URI, or by using some authentication 
mechanism on incoming messages. 


3.3. Usage Considerations 


It may at first seem strange to have a pointer to an archived form of 
a message in a header field of that same message. After all, if one 
has the message, why would one need a pointer to it? It turns out 
that such pointers can be extremely useful. This section describes 
some of the scenarios for their use. 


A user may want to refer to messages in a non-message context, such 
as on a Web page, in an instant message, or in a phone conversation. 
In such a case, the user can extract the URI from the Archived-At 
header field, avoiding the search for the correct message in the 
archive. 


A user may want to refer to other messages in a message context. 
Referring to a single message is often done by replying to that 
message. However, when referring to more than one message, providing 
pointers to archived messages is a widespread practice. The 
Archived-At header field makes it easier to provide these pointers. 
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A user may want to find messages related to a message at hand. The 
user may not have received the related messages, and therefore needs 
to use an archive. The user may also prefer finding related messages 
in the archive rather than in her MUA, because messages in archives 
may be linked in ways not provided by the MUA. The Archived-At 
header field provides a link to the starting point in the archive 
from which to find related messages. 


Please note that in the above usage scenarios, it is mostly the human 
reader, rather than the email client software, that makes use of the 
URI in the Archived-At header. However, this does not rule out the 
use of the URI in the Archived-At header by the email client or other 
software if such use is found helpful. 


4. Security Considerations 


There are many potential security issues when activating and 
dereferencing a URI. For more details, including some 
countermeasures, please see [STD66]. In the context of this 
proposal, the following are particularly relevant: An intruder may 
get access to the message transmission and be able to insert a URI 
pointing to some malicious content. This can be addressed by using a 
secured way of message transmission. Also, somebody may be able to 
construct a message that is harmless when received directly, but that 
produces problems when accessed via the URI. One reason for this may 
be the format used in the archive, where some content was not 
adequately escaped. This can be addressed by using adequate 
escaping. 


The Archived-At header field points to some archived form of the 
message itself. This in turn may contain the Archived-At field. 

This creates a potential for a denial-of-service attack on the server 
pointed to by the URI in the Archived-At header field. The 
conditions are that the archived form of the message is downloaded 
automatically, and that further URIs in that message are followed and 
downloaded recursively without checking for already downloaded 
resources. However, this kind of scenario can easily be avoided by 
implementations. First, the URI in the Archived-At header field 
should not be dereferenced automatically. Second, appropriate 
measures for loop detection should be used. 


In Section 3.2, an attack is described that may break a URI toa 


message by introducing a new message with the same message 
identifier. Possible countermeasures are also discussed. 
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5. IANA Considerations 
5.1. Registration of the Archive-At Header Field 


IANA has registered the Archived-At header field in the Message 
Header Fields Registry ([RFC3864]) as follows: 


Header field name: 
Archived-At 


Applicable protocol: 
mail (RFC 2822) and netnews (RFC 1036) 


Status: 
standard 


Author/Change controller: 
IETF 


Specification document(s): 
RFC 5064 


Related information: 
none 


5.2. Registration of the X-Archived-At Header Field 


This section is non-normative (specifically, an implementation that 
ignores this section remains compliant with this specification). 


IANA has registered the X-Archived-At header field in the Message 
Header Fields Registry ([RFC3864]) as follows: 


Header field name: 
X-Archived-At 


Applicable protocol: 
mail (RFC 2822) and netnews (RFC 1036) 


Status: 
deprecated 


Author/Change controller: 
IETF 


Specification document(s): 
RFC 5064 
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Related information: 
none 
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